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EXECUTIVE SUMMARY 


This is an analysis of the impact of Remotely Operated Aircraft (ROA) operations 
on current and planned, during the next decade, Air Traffic Control (ATC) automation 
systems in the En Route, Tenninal, and Traffic Flow Management domains. 

The operational aspects of ROA flight, while similar, are not entirely identical to 
their manned counterparts and may not have been considered within the time-horizons of 
the automation tools. This analysis was performed to determine if flight characteristics of 
ROAs would be compatible with current and future NAS automation tools. 

The following systems, categorized by areas of consideration, were evaluated in 
this analysis: 


En Route 

o Host Computer System (HCS) 

o 

Display System Replacement (DSR) 

o User Request Evaluation Tool 
(URET) 

o 

Center Terminal Radar Approach 
Control Automation System (CTAS) 

o En Route Automation Modernization 
System (ERAM) 

o 

Direct Access Radar Channel 
(DARC) 

Terminal 

o Automated Radar Terminal System 
(ARTS (II, HE, Microearts)) 

o 

Standard Terminal Automation 
Replacement System (STARS) 


Traffic Flow Management 

o Enhanced Traffic Management System (ETMS) 


This analysis determined that with minor modifications to URET, all other 
systems, current and planned, in the air traffic environment will perform normally with 
the introduction of ROAs in the NAS. 

Improvements to existing systems / processes are recommended that would give 
Air Traffic Controllers an indication that a particular aircraft is an ROA and 
modifications to IFR flight plan processing algorithms and / or designation of airspace 
where an ROA will be operating for long periods of time. 
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1.0 Introduction 

This is an analysis of the impact of Remotely Operated Aircraft (ROA) operations on 
current Air Traffic control (ATC) Automation systems and planned ATC automation 
systems during the next decade in the En Route, Terminal, and Traffic Flow Management 
Domains. 

1.1 Background 

Access 5 is a national project sponsored by the National Aeronautics and Space 
Administration (NASA), with participation by the Federal Aviation Administration 
(FAA), Department of Defense (DoD), and industry, to introduce civil High Altitude, 
Fong Endurance (HAFE) ROA to routine flight in the NAS. Access 5 commenced in 
May 2004 and is slated to run for five or more years. 

The goal of Access 5 is to assist in the development of policies and procedures, 
demonstrate the enabling technologies, and identify infrastructure to promote a robust 
civil market for HAFE ROA. Access 5 will address ROA airworthiness certification, 
flight operations, and crew certification. Project efforts will also include the development 
of appropriate standards, working where appropriate, through existing national standards 
groups. The project products are policy and procedure recommendations on ROA system 
airworthiness certification, ROA flight operations, ROA pilot certification, and 
appropriate standards. The project will identify mature technologies in several areas, 
including conflict avoidance and communications, and will also provide 
recommendations on maintenance for continued airworthiness, currency for pilots, and 
guidelines/processes for safe operation. 

Access 5 plans call for integrating HAFE ROA into the NAS through a four-step process: 

Step 1: Routine operations of HAFE ROA above Flight Fevel (FF) 400 (40,000 feet) 
with restrictions 

Step 2: Routine operations above FF180 (18,000 feet) with restrictions 

Step 3: Routine operations above FF180 and access to ROA designated airports with 
emergency landings in restricted areas 

Step 4: Routine operations above FF180 and access to ROA designated airports, 

including emergency landings (i.e., true "file-and-fly") 


1.2 Automation Impact of ROA’s in the NAS 

It was deemed necessary to evaluate the current and future NAS automation tools to 
determine the impact of adding a new class of air-vehicle, the ROA, into the NAS. The 
operational aspects of ROA flight, while similar, are not entirely identical to their 
manned counterparts and may not have been considered within the time-horizons of the 
automation tools. An analysis was performed to determine if flight characteristics of 
ROAs would be compatible with current and future NAS automation tools. 
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Areas of consideration: 

En Route 

Terminal 

Traffic Flow Management 

Automation Associated with Each Area see (figure 1): 

En Route: Host, DSR, URET, CTAS, ERAM, DARC 
Terminal: ARTS (II, HE, Microearts), STARS 
Traffic Flow Management: ETMS 


1.3 En Route Automation Systems 

En route automation systems considered include Host, DSR, URET, CTAS, ERAM, and 
DARC. Host, DSR, and ERAM provide flight data, surveillance and track data 
processing and provide the display of surveillance, weather, and map information used by 
the en route air traffic controller. Direct Access Radar channel (DARC) provides the 
enroute controller a backup system that processes surveillance and track data only, with a 
limited set of functionality that the primary system provides. URET provides a medium 
term conflict probe capability, aircraft-to-aircraft and aircraft-to-airspace, and the ability 
to display and manipulate flight data electronically. ERAM is designed to replace Host, 
DSR, URET and the DARC automation systems. CTAS provides metering information 
to the air traffic controller. 


Assuming a filed Instrument Flight Rules (IFR) flight plan, surveillance data such as 
transponder returns, and VHF/UHF remote pilot/controller communications, there is very 
little constraint upon en route automation systems when dealing with Remotely Operated 
Aircraft (ROA). The automation systems would not be able to distinguish between an 
ROA and any other IFR aircraft operating in the NAS, except for the aircraft type, as 
filed in the flight plan. 


The main driver of data in the en route automation domain is flight and track data 
processed by the Host and ERAM systems. This flight and track data is then used by the 
URET and CTAS systems. The URET and CTAS automation systems will process data 
from an ROA flight identically as any other IFR flight. As long as the flight data, flight 
data updates, and track information is received, the URET and CTAS systems will 
perform normally. Interestingly, a minor modification to URET will be required for 
some ROA operations. It was determined that, for example, a slow moving ROA with a 
headwind greater than the filed TAS would pose a problem for the URET trajectory 
modeler. If, when building a trajectory, the predicted groundspeed is calculated to be less 
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than zero, the trajectory modeler is terminated and no trajectory is built. This is actually 
common when low speed High Altitude Long Endurance (HALE) aircraft climb through 
the jet stream to operating altitudes. A modification to the URET algorithms will be 
implemented in the 2006 timeframe. 


1.4 Terminal Automation Systems 

Terminal automation systems considered include ARTS (II, HE, Microearts), and 
STARS. These terminal automation systems provide the surveillance and track data 
processing and the display of surveillance, weather, and map information used by the 
terminal air traffic controller. 

Assuming a filed IFR flight plan, surveillance data such as transponder returns, and 
VHF/UHF remote pilot/controller communications, there is little constraint upon terminal 
automation systems when dealing with ROAs. The automation systems would not be 
able to distinguish between an ROA and any other IFR aircraft operating in the NAS, 
except for the aircraft type, as filed in the flight plan. 


Terminal automation systems, ARTS and STARS both process flight data and track data. 
When an IFR flight plan is filed, the terminal automation is supplied flight data by the 
appropriate Host or ERAM en route automation system. Flight data for an ROA flight 
would be identical to all other IFR flight data being exchanged between the en route and 
terminal automation systems. All automation functions such as tracking, short term 
conflict alert, and minimum safe altitude warning would function for the ROA flight in 
the same manner as any other IFR flight. An ROA may require flight solely within 
terminal airspace and without an IFR flight plan being filed, such as for a local test flight. 
Terminal automation systems will allow this as the controller can start a track and the 
automation will pair the track data with the beacon return. This function will be no 
different for an ROA as with any pop-up flight. 

Flight data for the air traffic controllers is presented in the form of a terminal flight strip. 
These are formatted for proposed flights, over flights, and arrival flights. These flight 
strips are supplied by the associated en route Host or ERAM system and will be no 
different for an ROA flight as with any other IFR flight. 


1.5 Traffic Flow Management Systems 

ETMS is the system used by Traffic Management Specialists to predict, on national and 
local scales, traffic surges, gaps, and volume based on current and anticipated airborne 
aircraft. Traffic Management Specialists evaluate the projected flow of traffic into 
airports and sectors, and then implement the least restrictive action necessary to ensure 
that traffic demand does not exceed system capacity. Monitor Alert, a part of ETMS, 
analyzes traffic demand for all airports, sectors, and airborne reporting fixes in the 
continental United States, and then automatically displays an alert when demand is 
predicted to exceed capacity in a particular area. 
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Assuming a filed IFR flight plan and surveillance track data such as supplied by the en 
route automation systems, there is little constraint upon traffic flow management systems 
when dealing with ROAs. The ETMS receives flight plan data and active track data for 
all IFR flights in the NAS. Each En Route Center automation system sends the ETMS 
updated tracking information for each flight on a 3 minute update interval. The ETMS 
also receives updated flight plan information whenever the flight plan is modified, for 
example, when an altitude or route is modified. The ETMS automation system would not 
be able to distinguish between an ROA and any other IFR aircraft operating in the NAS, 
except for the aircraft type, as filed in the flight plan. 

The Air Traffic Control domains considered, En route. Terminal, and Traffic Flow 
Management, along with their associated automation systems (see figure 2) work as a 
completely integrated system, with continuous passage of flight and surveillance data on 
a 24/7 basis. The introduction of ROAs into the Air Traffic environment pose no 
insurmountable challenge to the various automation systems currently in existence or 
planned within the next decade. 

It is perceived that air traffic controllers will want an indication that a particular aircraft is 
an ROA. This could be accomplished in all the automation systems in a similar way, 
highlighting of the data block, for example. This highlighting could be based on aircraft 
type, as filed in the IFR flight plan. 


1.6 Flight Plan Latency 

Concern has been expressed that some ROA missions may exceed the flight plan lifespan 
of existing and future automation systems. For example, a typical flight today in the 
NAS, that departs from Los Angeles and flies to New York, has a flight plan lifespan of 
2-4 hours. An ROA, on the other hand, depending on its particular mission, may need a 
flight plan lifespan of 2-7 days. In other words, its mission may require it to depart, 
proceed to its target or research area, loiter or fly a particular pattern which may last for 
several days, then proceed to its destination. The question then arises if the existing and 
planned automation systems will support this type of flight plan. 

After an IFR flight plan is filed, it ultimately resides in the database within the ARTCC 
that contains its departure point. The flight plan exists in this database as a proposed or 
inactive flight. Flight data is then presented to the controller, in either paper, or 
electronic form, an adapted number of minutes, typically 30 prior to the proposed 
departure time which is contained in the flight plan. This proposed flight plan will 
remain in the database of the ARTCC for an adapted number of minutes after the 
proposed departure time, typically equating to 2-4 hours, and will then be removed 
automatically. If the flight has not departed within this adapted time and the operator has 
not updated the proposed departure time, the flight plan will be removed and the pilot or 
operator is required to file a new flight plan and the sequence of events is repeated. This 
paradigm for proposed flight plans is also valid for ROA flight plans. 
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When a flight departs, the flight plan becomes active either through a manual entry by the 
controller or automatically through the terminal/enroute automation systems. Once 
airborne, the flight and flight data typically exist in the terminal automation system for 
15-30 minutes. The airspace surrounding an airport is typically small and the flight is 
assumed to proceed outbound, either into the en route environment, or into another 
(adjacent) approach control. This flight data is then purged automatically from the 
terminal automation system an adapted number of minutes after transfer of control to the 
en route facility or adjacent approach control. It is important to note that, in the case of 
an IFR flight plan, the flight data for the approach control is maintained and supplied by 
the host ARTCC. The flight data supplied by the host ARTCC is of 2 types. First, the 
flight data needed by the controller such as route information, type and equipment, 
beacon code, etc. is supplied via an interface to the En Route Host Computer System and 
is used to print flight progress strips. The flight data needed by the terminal automation 
system, on the other hand, contains different information and is supplied via the 
NAS/ARTS interface. 


The lifespan for a flight plan of an active flight is directly related to the aircraft speed, 
and the distance to be traveled within a single facility. Take the example of the LAX- 
JFK commercial turbojet flight. The inactive flight plan exists in the Los Angeles 
ARTCC and will populate the Southern California Tracon automation system at an 
adapted time before the proposed departure time. Flight progress strips are also printed at 
the Tracon, Tower, and first en route sector, at the adapted time. Note, for URET enroute 
facilities, the flight data also populates the appropriate departure list. When this flight 
departs, the flight data changes from inactive to active, and ultimately, the SOCAL 
Tracon works the aircraft to a point that it transfers control to Los Angeles Center. The 
terminal automation system then purges the flight data an adapted number of minutes 
after this transfer of ownership. This would happen, approximately, within 30 minutes 
after departure. Los Angeles Center will then work the aircraft, sector to sector, until 
transferring control to Albuquerque Center. It is roughly 370 NM to the Albuquerque 
boundary and the flight time for a turbojet would be approximately 40-45 minutes. 
Approximately 20-30 minutes prior to transfer of control to Albuquerque, the Los 
Angeles Center automation would send flight data to the Albuquerque Center computer. 
The Los Angeles Center flight data would then be purged in another 20 minutes. 
Albuquerque then transfers control to Kansas City, who, in turn transfers to Indianapolis, 
etc. 


The longest flight plan lifespan in this example would be that of Kansas City Center 
where the flight would exist in the Kansas City automation for approximately 2 hours. If 
the aircraft in this example were a single engine Cessna (with very large fuel tanks), 
rather than a multi engine turbojet, the lifespan in the Kansas city Automation would be 
increased to approximately 9 hours. 

Typically, flight plans in the NAS are assumed to have a duration of less than 24 hours. 
Commercial and General Aviation aircraft do not currently have the endurance to exceed 
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a 24 hour period. Military however, with refueling capability, can remain airborne for 
this length of time. They accomplish this through the use of filed delays at a specific fix 
(limited to 3 hours) or, more typically, will file a flight plan to a Military Operations Area 
(MO A), cancel the active flight plan upon arrival, and use a new flight plan when they 
are ready to depart the MOA. 

Consider now, an ROA based in Wichita Kansas, for example. Suppose its mission is to 
fly from Wichita to Garden City at an altitude of FL450, park or orbit for 3 days, and then 
return. Further, assume its filed TAS is 75 kts. Would existing and planned infrastructure 
allow such a flight plan to be filed and would the infrastructure process an active flight of 
this duration? This example is considering, for simplicity, the entire flight to be within 
the Kansas City ARTCC. 

The first constraint deals with the filed route of flight. There is a current limitation of 48 
route elements that may be filed in a single flight plan. If this flight were to file point-to- 
point, such as Latitude/Longitude to Latitude/Longitude, there can be no more than 48 
occurrences. Depending on the mission and particular pattern to be flown, it may be 
possible, if not practical, to be filed. A second, and more limiting constraint, are the time 
estimates over each fix in the route of flight. Current en route automation systems 
decompose the route of flight into a series of fixes, and associate an estimated time over 
each fix, called a coordination time. The system cannot process a coordination time in 
excess of 24 hours in the future due to its inability to associate a day with the time. 

A third constrain is the maximum delay time that may be filed at a particular fix. 
Currently, a delay at a fix may not exceed 22 hours in duration. 

Options: 

1 . Modify en route flight plan processing algorithms to allow for long duration flight 
plans. 

2. Modify en route flight plan processing algorithms to allow for long duration 
delays at a fix. 

3. Define Special Use Airspace (SUA) or Special Activity Airspace (SAA) for long 
duration loitering or maneuvering. This would be similar to a military operation 
where a flight plan would terminate at the airspace (or at a fix close to or within 
the airspace). The flight would transition to a second (proposed) flight plan upon 
mission completion and would then be cleared by Air Traffic Control to depart 
the SAA based on the new flight plan. 
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1.7 Automation System Descriptions 


The Display System Replacement (DSR) provides continuous real-time, automated 
support to air traffic controllers for the display of surveillance, flight data and other 
critical control infonnation. This information is processed by the Host and Oceanic 
Computer System Replacement (HOCSR) and the Enhanced Direct Access Radar 
Channel (ED ARC) subsystems. The DSR provides controller workstations, displays, and 
input/output devices and a communications infrastructure to connect the DSR with 
external processing elements of the en route ATC automation system. 

The Host Computer System (HCS) receives and processes surveillance reports, and flight 
plan information. The HCS sends search/beacon target, track and flight data, surveillance 
and alphanumeric weather information, time data, traffic management advisories and lists 
to the (Display System Replacement) DSR. The HCS associates surveillance-derived 
tracking information with flight-planning information. The DSR sends requests for flight 
data, flight data updates, and track control messages to the HCS. HCS-generated display 
orders are translated for use within the DSR workstation. While radar data processing is 
distributed among the terminal and En Route computer resources, the HCS performs 
virtually all of the flight data processing for its entire geographical area of responsibility. 
Every tower (ATCT) and terminal radar approach control (TRACON) relies exclusively 
on its parent HCS for flight data. 

The User Request Evaluation Tool (URET) provides conflict probe capabilities to the 
data controller display in the Air Route Traffic Control Centers (ARTCC) facilities. 
URET combines real-time flight plan and radar track data with site adaptation, aircraft 
performance characteristics, and winds and temperatures aloft to construct four 
dimensional flight profiles, or trajectories, for pre-departure and active flights. For active 
flights, it also adapts itself to the observed behavior of the aircraft, dynamically adjusting 
predicted speeds, climb rates, and descent rates based on the performance of each 
individual flight as it is tracked through en route airspace, all to maintain aircraft 
trajectories to get the best possible prediction of future aircraft positions. URET uses its 
predicted trajectories to continuously detect potential aircraft conflicts up to 20 minutes 
into the future and to provide strategic notification to the appropriate sector. URET 
enables controllers to "look ahead" for potential conflicts through "what if' trial planning 
of possible flight path amendments. It enables controllers to accommodate user-preferred, 
off-airway routing to enable aircraft to fly more efficient routes, which reduce time and 
fuel consumption. 

Center Terminal Radar Approach Control Automation System Build 1 (CTAS Build 1) 
includes Traffic Management Unit (TMU) capabilities (timelines, load graphs, automated 
miles-in-trail, and the situation display) and single center metering using miles-in-trail or 
time-based scheduling and meter lists on en route displays. 

The En Route Automation Modernization System (ERAM System) will replace the 
existing diverse but functionally unequal primary and backup channels (Host and DARC) 
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with redundant, functionally equivalent primary and backup channels. The new primary 
and backup channels achieve identical full functionality by using highly reliable fault 
tolerant processing elements running identical software. A tertiary system with diverse 
software, and physical and electronic isolation from the ERAM primary and back-up 
systems, will be maintained as fall back until the functionality, reliability, and availability 
of ERAM is demonstrated in the field. A training subsystem with functionality identical 
to the operational system will permit training to be conducted in parallel with operations. 


The Automated Radar Terminal System - Model HE ( ARTS HE) provides radar data 
processing (RDP) and decision support tools to the controller in the terminal 
environment. Utilized at low to medium-size Terminal Radar Control (TRACONs) 
Facilities the ARTS HE is capable of receiving input from up to 2 sensors, can process up 
to 256 tracks simultaneously, and support up to 22 displays. The ARTS HE implements 
the Common ARTS software for improved performance maintenance efficiency. The 
radar data processing (RDP) software provides automated surveillance tracking and 
display processing. Included in the ARTS HE software are decision support tools such as 
Minimum Safe Altitude Warning (MSAW), Conflict Alert (CA), Mode C intruder alert, 
Converging Runway Display Aid (CRD A), and Controller Automation Spacing Aid 
(CASA). 

The Automated Radar Terminal System - Model IIA (ARTS IIA) provides radar data 
processing (RDP) and decision support tools to the controller in the terminal 
environment. Utilized at small Terminal Radar Approach Controls (TRACONs), ARTS 
IIA is capable of receiving input from one sensors, can process up to 256 tracks 
simultaneously and support up to 1 1 displays. The radar data processing (RDP) software 
provides automated surveillance tracking and display processing. Included in the ARTS 
IIA software are the decision support tools, minimum safe altitude warning (MSAW) and 
conflict alert, (CA). 

The Automated Radar Terminal System - Model IIIA (ARTS IIIA) provides radar data 
processing (RDP) and decision support tools to the controller in the terminal 
environment. Utilized at larger airports, ARTS IIIA is capable of receiving input from up 
to three sensors, can process up to 900 tracks simultaneously and support up to 36 
displays. The RDP software provides automated surveillance tracking and display 
processing. Included in the ARTS IIIA software are decision support tools such as 
Minimum Safe Altitude Warning (MSAW), Conflict Alert (CA), Mode C intruder alert, 
Converging Runway Display Aid (CRDA), Final Monitor Aid (FMA), and controller 
automation spacing aid. 

The Automated Radar Terminal System - Model HIE (ARTS HIE) consists of the 
hardware platform and software required providing radar data processing (RDP) and 
decision support tools to the controller in the terminal environment. The ARTS HIE is 
used at consolidated Terminal Radar Approach Control (TRACON) facilities. The 
Common ARTS program provided an ARTS HIE capable of receiving input from up to 
15 sensors, the ability to process up to 10,000 tracks simultaneously, and support up to 
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223 displays. The RDP software provides automated surveillance tracking and display 
processing including mosaic display of radar data. Included in the ARTS HIE software 
are decision support tools such as Minimum Safe Altitude Warning (MSAW), Conflict 
Alert (CA), Mode C intruder alert, Converging Runway Display Aid (CRD A), Final 
Monitor Aid (FMA), and controller automation spacing aid. 

The Microprocessor-En Route Automated Radar Tracking System (Micro-EARTS) is a 
radar processing system implemented with Commercial Off-the-Shelf (COTS) 
equipment, for use in both En Route and Terminal environments. It provides single 
sensor and a mosaic display of traffic and weather using long- and short-range radars. At 
Anchorage, Alaska, Micro-EARTS also provides Automatic Dependent Surveillance- 
Broadcast (ADS-B) surveillance and display. Micro-EARTS interfaces with multiple 
types of displays, including Display System Replacement (DSR), Digital Bright Radar 
Indicator Tower Equipment (DBRITE), and the flat panel tower controller displays. 

The Enhanced Traffic Management System (ETMS) application is at the heart of the 
Traffic Flow Management (TFM) system, and through it flows the network of all TFM 
interfaces. ETMS at the Command Center deals with the strategic flow of air traffic at the 
national level. ETMS at remote facilities is used for local airspace management within 
the local facility’s own area of responsibility. To facilitate coordination between the 
Traffic Management Coordinators (TMC) at remote Traffic Management Units (TMUs) 
and the Traffic Management Specialists (TMS) at the Air Traffic Control System 
Command Center (ARTSCC), each local ETMS may also view the national composite 
picture of traffic for which the Command Center has responsibility. ETMS enables TMS 
and TMC personnel to track and predict traffic flows, analyze effects of ground delays or 
weather delays, evaluate alternative routing strategies, and plan traffic flow patterns. 

The Direct Access Radar Channel (DARC) provides a back-up processing path to provide 
surveillance data to the displays in the event of a primary channel (Host Computer 
System (HCS) failure. The DARC path is a physically, logically and electrically separate 
processing path (with diverse hardware and software) from the primary Host Computer 
System (HCS) Radar Data Processing (RDP) paths. Thus DARC provides a tertiary path, 
to keep radar data on the controller’s displays, should both HCS RDP paths be disabled 
for any reason. The DARC provides radar data processing, very limited flight data 
processing, but with significantly less functionality than the HCS. Basically, DARC 
serves as a lifeboat should both HCS processing paths become disabled. 


The Standard Terminal Automation Replacement System (STARS) processes primary 
and secondary radar information to acquire and track data points to display aircraft 
position for controllers. STARS provides safety tools such as, conflict alert (CA), Mode 
C intruder (MCI), final monitoring aid (FMA), Minimum Safe Altitude Warning 
(MSAW), Converging Runway Display Aid (CARD A), and Controller Automated 
Spacing Aid (CASA). Also, STARS provides the capability to implement the following 
enhancements: improved radar processing, Global Positioning System (GPS) 
compatibility, adaptive routing, Center Terminal Radar Approach Control (TRACON) 
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Automation System (CTAS), data link implementation, improved weather display, and 
better utilization of traffic management information. 


1.8 Glossary 

ARTCC 

Air Route Traffic Control Center 

ARTS 

Automated Radar Terminal System 

CTAS 

Center Tracon Automation System 

DARC 

Direct Access Radar Channel 

DSR 

Display system Replacement 

ERAM 

En Route Automation Modernization 

ETMS 

Enhanced Traffic Management System 

HALE 

High Altitude Long Endurance 

IFR 

Instrument Flight Rules 

MOA 

Military Operations Area 

NAS 

National Airspace System 

ROA 

Remotely Operated Aircraft 

SAA 

Special Activity Airspace 

SUA 

Special Use Airspace 

STARS 

Standard Terminal Automation Replacement System 

TAS 

True Air Speed 

TRACON 

Terminal Radar Approach Control 

UHF 

Ultra High Frequency 

URET 

User Request Evaluation Tool 

VHF 

Very High Frequency 
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Figure i NAS Automation Flow 
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Figure 2 NAS Automation Connectivity 
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